The development of Gnus normally is done on the Git repository trunk as of April 19, 2010 (formerly it was done in CVS; the repository is at http://git.gnus.org), i.e. there are no separate branches to develop and test new features. Most of the time, the trunk is developed quite actively with more or less daily changes. Only after a new major release, e.g. 5.10.1, there's usually a feature period of several months. After the release of Gnus 5.10.6 the development of new features started again on the trunk while the 5.10 series is continued on the stable branch (v5-10) from which more stable releases will be done when needed (5.10.8, ...). Gnus Development
Stable releases of Gnus finally become part of Emacs. E.g. Gnus 5.8 became a part of Emacs 21 (relabeled to Gnus 5.9). The 5.10 series became part of Emacs 22 as Gnus 5.11.
In the past, the inclusion of Gnus into Emacs was quite cumbersome. For each change made to Gnus in Emacs repository, it had to be checked that it was applied to the new Gnus version, too. Else, bug fixes done in Emacs repository might have been lost.
With the inclusion of Gnus 5.10, Miles Bader has set up an Emacs-Gnus gateway to ensure the bug fixes from Emacs CVS are propagated to Gnus CVS semi-automatically.
After Emacs moved to bzr and Gnus moved to git, Katsumi Yamaoka has taken over the chore of keeping Emacs and Gnus in sync. In general, changes made to one repository will usually be replicated in the other within a few days.
Basically the idea is that the gateway will cause all common files in Emacs and Gnus v5-13 to be identical except when there's a very good reason (e.g., the Gnus version string in Emacs says ‘5.11’, but the v5-13 version string remains ‘5.13.x’). Furthermore, all changes in these files in either Emacs or the v5-13 branch will be installed into the Gnus git trunk, again except where there's a good reason.
Because of this, when the next major version of Gnus will be included in Emacs, it should be very easy – just plonk in the files from the Gnus trunk without worrying about lost changes from the Emacs tree.
The effect of this is that as hacker, you should generally only have to make changes in one place:
If you don't have Emacs bzr access (or it's inconvenient), you can change such a file in the v5-10 branch, and it should propagate to Emacs bzr – however, it will get some extra scrutiny (by Miles) to see if the changes are possibly controversial and need discussion on the mailing list. Many changes are obvious bug-fixes however, so often there won't be any problem.
If you know that there will be conflicts (perhaps because the affected source code is different in v5-10 and the Gnus git trunk), then you can install your change in both places, and when I try to sync them, there will be a conflict – however, since in most such cases there would be a conflict anyway, it's often easier for me to resolve it simply if I see two ‘identical’ changes, and can just choose the proper one, rather than having to actually fix the code.
Of course in any case, if you just can't wait for me to sync your change, you can commit it in more than one place and probably there will be no problem; usually the changes are textually identical anyway, so can be easily resolved automatically (sometimes I notice silly things in such multiple commits, like whitespace differences, and unify those ;-).
Starting from No Gnus, the GNUS-NEWS is created from texi/gnus-news.texi. Don't edit GNUS-NEWS. Edit texi/gnus-news.texi, type make GNUS-NEWS in the texi directory and commit GNUS-NEWS and texi/gnus-news.texi.
For new customizable variables introduced in Oort Gnus
(including the v5-10 branch) use :version "22.1" ;; Oort
Gnus (including the comment) or e.g. :version "22.2"
;; Gnus 5.10.10 if the feature was added for Emacs 22.2
and Gnus 5.10.10. If the variable is new in No Gnus use
:version "23.1" ;; No Gnus.
The same applies for customizable variables when its default value was changed.